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Description 

Technical Field 

[0001 ] This invention relates to methods and appara- 
tus for generating telephony service detail records, and 
to monitoring systems for collecting data for these 
records from a network, such as a packet data network, 
which is used tor example to carry multimedia services 
{as described in ITU recommendation H.323 or the 
IETF SIP standard). 

Background 

[0002] The provision of multimedia communications 
services over a packet data network (PDN) which may 
not provide quality of service guarantees has recently 
generated a great deal of interest due to the success of 
networks based on the internet protocols (TCP/IP). Net- 
work operators are currently trialing multimedia commu- 
nications services over a variety of packet data 
networks such as IP, Frame Relay (FR) and Asynchro- 
nous Transfer Mode (ATM). A major problem is to gen- 
erate service detail records (generalised call data 
records), in real-lime or batch-mode, which measure 
the service usage of individual users and the service 
quality that was actually experienced by the user. 

Disclosure of Invention 

[0003] The invention described here enables a net- 
work operator to generate such records on a pure PDN, 
or on a hybrid network of interconnected PDNs and 
switched circuit networks (SCNs). It also includes a 
method for automatically discovering the network con- 
figuration information, including addressing and identi- 
fying the relationships between gatekeepers and 
endpoints. 

[0004] According to one aspect of this invention there 
is provided a method of monitoring a packet data sub- 
network (e.g. ethernet segment) or link (e.g. a T3 link 
carrying IP over PPP), comprising the steps of monitor- 
ing at a first location signalling messages to detect the 
existence of a call; and monitoring at multiple other 
locations to identify some or all packets associated with 
the call (in H.323, the Call ID can be used to identify all 
packets associated with a given call). The captured 
packets may include both signalling data and data from 
multimedia streams associated with the call. It may be 
required for wire-tap applications, for example, to use 
the signalling data to identify calls of interest, and then 
capture the entire multimedia stream. It may be neces- 
sary to buffer captured packets at each location to 
ensure that all packets associated with the call could be 
captured. 

[0005] In addition, the packets associated with a con- 
ference call can be correlated together to form a service 
record for a conference call. This can be achieved by 



capturing all packets with the same conference ID in 
H.323, tor example. 

[0006] In some cases it may be desirable to monitor 
additional signalling messages, e.g. Signalling System 

5 No. 7 (SS7) protocol messages or Integrated Services 
Digital Network (ISDN) messages, on signalling links in 
an SCN (such as the public switched telephone network 
- PSTN) coupled to said packet data network, to derive 
additional monitoring data, and correlate those addi- 

w tional monitoring data with at least some of first monitor- 
ing data. These can be correlated to the original call by 
using characteristics such as calling or called party 
numbers to identify the call. 

[0007] Other aspects of the invention are identified in 
is the appended claims. 

Brief Description of Drawings 



20 



[0008] Methods and apparatus in accordance with this 
invention for generating telephone service detail 
records will now be described, by way of example, with 
reference to the accompanying drawings, in which: 

Figure 1 shows a distributed monitoring system for 
25 a PDN carrying multimedia voice services; 

Figure 2 shows examples of extensions of this 
architecture to correlate data from the PDN 
with signalling data from the SCN; 
Figure 3 shows the sequence of message types 
30 which can be captured to construct a serv- 

ice detail record: and 
Figure 4 shows an example of the structure of a 
service record that could be constructed 
from the data collected by the monitoring 
35 system. 



Best Mode for Carrying Out the Invention. & Industrial 
Applicability 



40 [0009] The distributed monitoring system shown in the 
drawings has the capability to collect data from a com- 
bined PDN and SCN carrying multimedia services, cor- 
relate these data in real-time, and provide a real-time 
view of services on the network. These data can be 

45 used for applications such as troubleshooting, surveil- 
lance, security, network planning, provision of account- 
ing information to customers, fraud detection, billing and 
acquisition of marketing information. 
[0010] Referring to Figure 1, the probes shown are 

so part of a distributed monitoring system, and are link 
monitoring devices (using techniques similar to those in 
existing protocol analysers for example). The distributed 
monitoring system is constructed from the probes and 
standard computer and communications components, 

55 with special-purpose software which provides the appli- 
cations described above. A principal function of this 
software is to correlate data from different probes to 
provide a record or real-time trace of calls, transactions 



BNSDOCID: <EP 0948163A1_L> 



2 



1 



3 EP 0 948 163 A1 4 



and other services as they occur on the network. The 
Hewlett-Packard acceSS7 system is an example of a 
distributed monitoring system which could be used to 
implement parts of the system described above. 
[001 1 ] An example of a monitoring system architec- 
ture is given in Figure 2. This shows probes monitoring 
the PDN, SS7 network and the ISDN. The SS7 probes 
could be for example from the Hewlett-Packard 
acceSS7 system. The ISDN primary rate access 
probes could for example be constructed using the 
same techniques as in existing protocol analysers (such 
as the Hewlett-Packard 37900D Signalling Test Set). 
The PDN probes could be constructed from the Hewlett- 
Packard Lan Probes for example. 
[0012] The distributed monitoring system is arranged 
to correlate real-time data from any combination of 
these probes. This includes, for example, signalling data 
from the SS7 links, signalling from the ISDN links (e.g. 
the D-channel for N-ISDN), the signalling data for the 
multimedia service from the PDN, and the multimedia 
stream data (e.g. data indicating packet loss, latency or 
jitter). It may also include the capture of the entire multi- 
media stream for applications like wire tapping or trou- 
bleshooting. 

[001 3] For convenience the invention is described pri- 
marily with reference to the H.323 recommendation, 
using IP as the PDN, and optionally connected to one or 
more SCNs using narrowband ISDN and/or SS7 signal- 
ling with trunk connections. However, it should be 
understood that this terminology is to be taken as 
including within its scope analogous functionality, 
whether or not they are customarily identified by the 
terms used in these standard recommendations. 

AUTO-DISCOVERY PROCESS 

[001 4] The PDN is continuously monitored for packets 
that provide configuration information on H.323 end- 
points and gateways. These packets may be captured 
to create and maintain a database (the network discov- 
ery database) which gives configuration information, 
addressing information and relationships between the 
endpoints and gateways. The network discovery data- 
base may also take data from additional sources to sup- 
plement or verify the captured data Any discrepancies 
between the discovered data and the data from other 
sources should be used to generate an alarm to the net- 
work operator indicating a possible network configura- 
tion problem. The details of the data captured are 
described in the following paragraphs. 
[001 5) A type of transaction which is tracked by the 
monitoring system is the gateway discovery process. 
This is used by an endpoint to automatically find a gate- 
keeper which will provide service to it. The monitoring 
system uses the data captured from the sequence of 
messages between the endpoint and the gatekeeper, to 
identify endpoints and gateways and to build a database 
of the relationships between endpoints and gatekeeper. 



The database stores information derived from the cap- 
tured data which identifies the endpoint and gatekeeper. 
This includes the network addresses and port numbers. 
The monitoring system monitors continuously for end- 

s point discovery attempts, to maintain an accurate data- 
base of the network configuration. 
[0016] The endpoints may go through a registration 
process with its gatekeeper. This process may be 
repeated periodically H the registration has a finite Irfe- 

w time. The monitoring system monitors the network con- 
tinuously for packets involved in the registration 
process. The monitoring system captures the relevant 
packets and uses the data relating to the endpoint and 
gateway to update and add information to the database. 

75 This typically includes any transport addresses (trans- 
port address =(Network address, TSAP or port 
number)), any alias addresses and any other address- 
ing or configuration information associated with the end- 
point or gateway. 

20 [001 7] Endpoints may also request from a gatekeeper 
location information for an endpoint for which it has the 
alias. The monitoring system will continuously monitor 
for the exchange of packets associated with this loca- 
tion process and capture data from the relevant packets. 

25 This data can be used to update or add information to 
the network discovery database that identifies the rela- 
tionship between aliases, transport addresses and any 
other addressing or configuration information. This may 
include information which identifies how to connect to a 

30 destination on the SCN (e.g. E.164 addresses). 

[0018] Access tokens may be used to enable an end- 
point to hide its transport address from the endpoint to 
which, it is establishing communication. The monitoring 
system will continuously monitor the network to capture 

35 packets that are used in the process of distributing 
access tokens to endpoints. The captured data is used 
to add to or update information in the network database 
indicating the association between an access token and 
an endpoint. 

40 

GENERATION OF SERVICE RECORDS 

[0019] This section lists the types of fields in service 
records, and descrfoes how the distributed monitoring 

45 system could provide the required data. A service 
record is generated for each instance of the usage of a 
specific service. This is a generalisation of a call record, 
which is generated by current switches. A service is nor- 
mally defined from the perspective of the user. The 

so service may actually involve a number of calls or trans- 
actions, for example. In the case where only the PDN is 
being monitored, these service records include data 
from the signalling between any combination of gate- 
ways, gatekeepers, terminals and multi-point control - 

55 lers; and data from the multimedia streams controlled 
by this signalling. In the case where the SCNs con- 
nected to the PDN are being monitored, the service 
record will also include data from the signalling data on 
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the SCN collected from the probes connected to the 
SCN. The network discovery database may be used in 
constructing the service records to fill any address or 
configuration information which is not available directly 
from the packets involved in the call. 5 
[0020] Figure 3 shows an example of the sequence of 
packets which may be captured at different levels in the 
overall stack of protocols (such as Q.931, H.245 and an 
unreliable datagram protocol - UDP) to provide a serv- 
ice detail record. Figure 4 illustrates how the information w 
from these different parts of the overall transaction can 
be used to contribute to different respective parts of a 
service detail record. 



1. Calling Party Information. 



15 



[0021] This includes any information which can be 
derived about the calling party from the signalling data 
flowing on the PDN, and is therefore available to the link 
monitoring probes. Typical information includes: calling 20 
party number; any ISDN sub-addressing information; 
calling party name; network addresses; TSAP or port 
numbers; alias addresses; and any numbers or 
addresses related to billing. This information can be 
derived from the sequence of messages used to setup 25 
a call. In the H.323 recommendation, this can be 
achieved by extracting the relevant fields from the Q.931 
messages used in setting up the call (set-up. call pro- 
ceeding, alerting, connect for example). In the cases 
where one or more gatekeepers are involved the admis- 30 
sion signalling (H.225 ARQ and ACF messages for 
example) between gatekeeper and endpoint is captured 
to identify the logical channel for call signalling. The log- 
ical channel is typically identified using the transport 
address. 35 
[0022] Additional information may be derived from call 
setup messages on the ISDN D channels of an inter- 
connected SCN, at either the originating or terminating 
end or both; and/or from call setup messages on any of 
the SS7 links of the SCN. Additional information may 40 
also be derived from any intelligent network service 
messages that flow over the SS7 links as part of the 
specific service usage. 



2. Called Party Information. 

[0023] As for calling party information, but replace 
calling party by called party. 

3. Information on each party in a conference. 



45 



so 



[0024] The equivalent data to the calling party infor- 
mation for each party in a conference, with additional 
information on the conference objective Qoin confer- 
ence, create coinference or invite for example) and a 55 
means to identify the conference ( Conference ID for 
example). 



4. Network Routing and Logical Channel Information. 

[0025] This may include any information on the net- 
work resources which were used to provide this specific 
service usage. The following are examples of data 
which might be provided: 

logical channels associated with the call and their 
identifiers, 

- the requested media, codecs (coder/decoders), 
service quality and bandwidth for each channel, 
the negotiated media, codecs, service quality and 
bandwidth for each channel, 
any other performance or configuration data on the 
channels which are requested or established during 
the call or conference. 

Each of these uses is time-stamped, and the sequence 
and nature of the use indicated. These data can be 
obtained in a similar way as was described for item 1 
above from the capture of packets carrying signalling 
information. More specifically the logical channels can 
be identified by using the fields within an OpenLogical- 
Channel structure within certain messages defined in 
H.323 and associated recommendations. Subsequent 
messages which control the logical channels are also 
monitored and any changes in channel configuration 
can be time stamped and added to the service record. 
[0026] A important additional set of information is the 
measured quality of service and bandwidth usage on 
each of the logical channels set-up as part of the call. 
This will typically include packet loss rates, latency and 
jitter measurements which are made over selected 
intervals by capturing packets from the logical channels 
and extracting the relevant fields. 

5. Supplementary Services Information. 

[0027] This may include any information on supple- 
mentary services used for this specific service usage. 
The following are some examples of the data which may 
be provided: 

call forwarding indication and address information; 
interactive voice response information on the use of 
intelligent peripherals; 
800 number services; 

any custom services that may be invoked during the 
call or conference. 

This information includes time-stamps, duration and the 
nature of the use. These data can be obtained in a sim- 
ilar way as was described for item 1 above. 

6. Service Status and Termination Information. 

[0028] This may include time-stamped information on 
the initiation of the service, time-stamped information on 
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any status changes occurring during service and time- 
stamped information on the termination of the service. 
The termination information should include the reasons 
for termination. 

[0029] These data call be obtained in a similar way as 
was described for item 1 above. In particular, the H.245 
end Session Command message and the Q.931 call ter- 
mination messages, the call clearing messages on the 
SS7 links and the ISDN D channels can provide details 
on the reasons for call termination. 

7. Additional Service Quality Information. 

[0030] The service quality information provided is 
dependent on the service indicated in the service type 
field. The following gives some examples of what call be 
provided for specific services. 

[0031 ] Voice quality is mainly indicated by the bit error 
rate, jitter and delay. These parameters can be meas- 
ured using a passive monitoring system and monitoring 
at two points in the network. Signalling information can 
be used to identify the logical channels on the PDN, the 
ISDN B channels or the time slots on SCN trunks, that 
are carrying the voice signals. The bit streams from 
each of the channels or trunk time slots identified can 
be compared to derive the delay, jitter and bit error rate 
caused by the intermediate networks. 

8. Service Usage Information. 

[0032] The type of usage data provided by the distrib- 
uted monitoring system depends on the specific serv- 
ice. Some examples follow. 

[0033] Voice, video and fax services require call dura- 
tion and used bandwidth. 

[0034] The data oriented services require data such 
as total bits, frames and packets in each direction. This 
may be provided for regular time intervals for the dura- 
tion of the service. It may also be broken down into a 
traffic matrix, where the data protocol has additional 
addressing information (such as IP addresses). The 
data are obtained in a similar way as is described for 
item 1 above. 

9. Security Information. 

[0035] A particular instance of service usage may be 
an attempt to obtain unauthorised access to resources. 
The service record includes information which may indi- 
cate this type of behaviour. This may include information 
about the duration of call, the way the call was termi- 
nated and details of the service used. 
[0036] An example would be where there are 
repeated failed attempts to gain access to different 
resources. 



8 

REAL-TIME UPDATES ON SERVICE USE 

[0037] The data that populates the service records 
described in the previous section can be collected in 

5 real-time from the monitoring probes. These data can 
be provided in real-time on remotely connected comput- 
ers, as they become available. A user of the distributed 
monitoring system can apply filtering criteria on any of 
the information described in the previous section, to 

io sel ect those i nstances of service use for whi ch real -time 
updates are required. 

WIRE-TAP CAPABILITY 

is [0038] Any of the data extracted from the signalling 
messages can be used to match criteria set by the user 
of the monitoring system and trigger some or all of the 
logical channels to be captured in their entirety. This 
technique can be used to provide a wire-tap capability, 

20 which would allow real-time copies of the media 
streams to be routed through the monitoring system to 
a third party, or stored for analysis. The filtering could 
also be on characteristics in the media stream (for 
example, a specific spoken word in an audio stream) 

25 which, if matched, would trigger the capture of all the 
service record information from the signalling mes- 
sages, as described earlier. 

APPLICATIONS 

30 

[0039] The following applications can be implemented 
using the data from the service records described 
above or the real-time service updates. Data from other 
sources may be used to enhance the effectiveness of 
35 these applications. 

A. Quality of Service and Service Level Agreements. 

[0040] The service records described above can be 
40 used to provide service quality information on selected 
customer s service. This can be used to track conform- 
ance to service level agreements, and be provided to 
the customer as an additional service. It can be pro- 
vided as periodic reports, or in real-time using the real- 
45 time updates described above. 

B. Surveillance and Troubleshooting for Network Opera- 
tions. 

so [0041 ] The service records and real-time updates can 
be used to identify service or network faults. The infor- 
mation can also be used to troubleshoot the faults. 

C. Fraud Detection. 

55 

[0042] The service records and real -time updates can 
be used to identify potential fraudulent use of the net- 
work or service. Indications may include excessive use 
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of high value services, unusual call termination behav- 
iour and repeated failures to gain access to a service. 
The distributed monitoring system may be used to track 
the service usage of potential high-risk users in real- 
time. 

D. Security and Hacking Detection 

[0043] Potential security threats can be identified by 
repeated failures to gain access to a service. They also 
may be indicated by, successful access to sensitive 
services, such as maintenance ports on customer 
premises equipment (CPE). This type of data is availa- 
ble from the service records and the real-time updates. 

E. Billing Data 

[0044] The service records can be used as a basis for 
billing which is dependent on any of the fields in the 
service record. This allows for example, billing to be 
based on the actual service quality delivered. It also 
enables billing to reflect the nature and generation of 
the usage of resources on the network, such as intelli- 
gent peripherals and databases. The billing data could 
be made available in real-time. 

F. Customer Accounting Data 

[0045] The detailed service usage information in the 
service records can be provided to customers for use in 
their internal accounting. This includes the traffic matrix 
information for packet and frame based protocols, which 
the system derives from the B and D ISDN channels. 

G. Customer and Telecom Operator Network Planning 35 

[0046] The service records can provide detailed infor- 
mation on the use of network resources which can be 
provided to network planning departments within the 
operator and the customer. <o 

H. Wire-tap 



[0047] The wire-tap capability described above can be 
used to provide wire tap services to authorized third 
parties, and potentially as a trouble shooting tool. 

Claims 

1 . A method of generating generalised service detail 
records for telephony communications carried over 
a packet network, comprising the steps of: 

acquiring packet network service data from 
packets carrying the telephony communica- 
tions; 

acquiring signalling data from a signalling pro- 
tocol to identify at least one of addressing, COn- 



70 



15 



20 



25 



30 



45 



figuration, status and timing information for 
endpoints, gatekeepers and connections 
involved in a call; and 

combining said packet service data and said 
signalling data to generate service detail 
records. 

2. The method of claim 1 , wherein some or all of the 
data is captured by a passive monitoring system. 

3. The method of claim i, wherein packet network 
service data are acquired from the protocol head- 
ers of the packets carrying the signalling data for 
the telephony service. 

4. The method of claim 1 , including using the informa- 
tion captured in the signalling messages to identify 
the logical channels carrying the media streams, 
and capture some or all of the packets on the logi- 
cal channels in real-time at one or more points in 
the network. 

5. The method of claim 4, wherein captured data are 
used to measure the quality of service actually 
achieved by each channel. 

6. The method of claim 1 , including using the informa- 
tion captured in the signalling messages to identify 
the logical channels carrying the media streams, 
and capture some or all of the packets on the logi- 
cal channels in real-time at one or more points in 
the network. 

7. The method of claim 6, wherein captured data are 
used to provide secret access to the media stream 
for troubleshooting or surveillance purposes. 

8. The method of claim 7, wherein addressing infor- 
mation for the target user is used to select the cor- 
rect signalling packets, potentially in conjunction 
with data from a network discovery database. 

9. The method of claim 1, including correlating the 
data from the PDN with data collected from an SCN 
{such as a PSTN, ISDN or B-ISDN) to enhance the 
generalised service detail records. 



10. The method of claim 9, including use of data col- 
lected from passive monitoring of the signalling net- 
so work (e.g. SS7) or access signalling (e.g. ISDN, B- 

ISDN). 

11. The method of claim 9, including use of data col- 
lected from the transmission network for audio or 

55 video quality. 

12. The method of claim 1 , including using the general- 
ised service detail records to bill for the telephony 
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service, optionally taking into account the quality of 
service and usage data, and optionally including 
tracking to see if customers have been exceeding 
their agreed bandwidth constraints. 

5 

1 3. The method of claim 1 , including using the general- 
ised service detail records to detect potentially 
fraudulent service usage, perform network plan- 
ning, perform marketing studies, perform network 
operations funtions, modify the network configura- 10 
tion in real-time to achieve quality of service objec- 
tives, and/or perform customer care functions. 

14. A method of discovering the network configuration 

of the endpoints, gatekeepers and their relation- is 
ships, tor a telephony communications service car- 
ried by a PDN, by using a passive monitoring 
system to capturing the signalling messages 
involved in the configuration and negotiation of rela- 
tionships, addressing and resource allocation, so 
between endpoints and gatekeepers. 

1 5. A method of generating generalised service detail 
records for telephony communications carried over 

a packet network comprising the steps of: 25 

acquiring packet network service data for the 
packets carrying the telephony service; 
acquiring signalling data regarding at least one 
of call control, registration, admissions, band- 30 
width management, call status, address trans- 
lation and intelligent network services; 
acquiring quality of service data for the teleph- 
ony service transmission level; and 
combining said service data, said signalling 35 
data and said quality of service data to gener- 
ate generalised service detail records. 

16. The method of any one of the preceding claims, 
wherein the capture of packets is performed at mul- 40 
tiple points in real time; and then correlated in real- 
time. 

17. The method of any one of the preceding claims, 
wherein the telephony communications comprise 45 
real-time voice or audio, fax, voice-messaging, real 
time video or multimedia communications. 

18. The method of any one of the preceding claims 
wherein the packet network is an IP, frame relay or so 
ATM network. 

1 9. A' method of monitoring a packet data sub-network 
or link, comprising the steps of: monitoring at a first 
location signalling messages to detect the exist- ss 
ence of a call; and monitoring at multiple other loca- 
tions to identify some or all packets associated with 
the call. 
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